1. Technical Field
The present invention relates to debugging multiple related processes simultaneously. More particularly, this invention relates to debugging multiple related processes simultaneously from one instance of a debugger
2. Prior Art
As part of the development of software applications, software programmers frequently must xe2x80x9cdebugxe2x80x9d their code to ensure it operates properly and without interruption. There are numerous debugging methods and techniques, including special debugging application programming interfaces and breakpoints. To aid programmers, debugging programs or debuggers have been developed. Debuggers can be stand-alone or integrated into another software application such as an object-oriented application development environment.
Many of the current state-of-the-art debuggers do not simultaneously debug multiple related processes (programs) using one instance of the debugger. Related processes are processes that are spawned, directly or indirectly, from a single process. For example, a parent process may spawn child related processes and in turn, the child related processes may act as a parent process spawning further child related processes; all processes spawned in this manner are related to each other. To debug related processes, a user often must start one or more instances of a debugger to debug a parent process and its child process(es). And, an example of debuggers heretofore not simultaneously debugging multiple related processes using one instance of a debugger are those designed for the Microsoft Windows NT(copyright) and Windows(copyright) 95 operating systems.
Debugging multiple related processes simultaneously can be important since processes often work in conjunction with other processes. One such example is the xe2x80x9cProducerxe2x80x9d/xe2x80x9cConsumerxe2x80x9d problem where one process produces data or information that another process requires as input. Being able to debug both the Producer process and Consumer process simultaneously has advantages, especially when the communication between the two processes are asynchronous and the events sent between the Producer and Consumer occur at non-deterministic rates or occur in a non-deterministic ordering. Being able to debug both processes simultaneously gives the user more control in recreating the specific ordering of events that generate a failure in processing. Further, being able to debug both processes simultaneously from the same instance of the debugger provides usability gains and convenience by for example allowing the user to view information flowing between processes and the states of the processes.
In the Windows NT and Windows 95 operating systems, the problem of debugging related processes can be understood by examining the application programming interface (API) functions these operating systems provide which allow debuggers to perform process control. In particular, the functions WaitForDebugEvent( ) and ContinueDebugEvent( ) are provided by Windows NT and Windows 95 to debug a process. The first function, WaitForDebugEvent( ), monitors for the occurrence of a debug event in a process that has been initiated for debugging by the function ContinueDebugEvent( ). When a debug event occurs in a process, that process is stalled. Debug events can include the spawning of a child process or a programming fault. The second function, ContinueDebugEvent( ), initiates debugging of a process and continues debugging of a process if the process has been stalled due to the occurrence of a debug event observed by the function WaitForDebugEvent( ). A key constraint that both these functions share is that only the thread that created the process being debugged can call WaitForDebugEvent( ) or ContinueDebugEvent( ). Therefore, debugging related processes in a single instance of a debugger has been constrained. As has been known in the art debugging related processes can be performed by invoking multiple instances of a debugger. Invoking multiple instances of a debugger has the apparent disadvantages of using more computer resources such as processing and memory.
As a pseudocode example, the following function, CreateProcesso ( ), can be used to create a process on the Windows NT and Windows 95 operating systems:
BOOL CreateProcess(LPCTSTR lpApplicationName,
LPSTR lpCommandLine,
LPSECURITY_ATTRIBUTES lpProcessAttributes,
LPSECURITY_ATTRIBUTES lpThreadAttributes,
BOOL bInheritHandles,
DWORD dwCreationFlags,
LPVOID lpEnvironment,
LPCTSTR lpCurrentDirectory,
LPSTARTUPINFO lpStartupInfo,
LPPROCESS_INFORMATION lpProcessInformation
);
The debugger loads the debuggee by making a call to CreateProcess( ). The thread which executes this call becomes the only thread that can thereafter make calls to WaitForDebugEvent( ) and ContinueDebugEvent( ). We can now refer to this thread as being xe2x80x9cspecialxe2x80x9d. Pseudocode to perform this might be as follows:
//executing on xe2x80x9cspecialxe2x80x9d debugger thread
//
PROCESS_INFORMATION process_info;
STARTUPINFO startup_info={0};
startup_info.cb=sizeof(STARTUPINFO);
CreateProcess(NULL,
xe2x80x9cexample.exexe2x80x9d,
NULL,
NULL,
False,
DEBUG_PROCESS¦ CREATE_NEW_CONSOLE|
NORMAL_PRIORITY_CLASS,
NULL,
NULL,
andstartup_info,
andprocess_info);
DWORD process_id=process_info.dwProcessId;
DWORD thread_id=process_info.dwThreadId;
Next, in order to run the newly created process, the debugger must issue a ContinueDebugEvent( ) from the xe2x80x9cspecialxe2x80x9d thread. This allows the newly created debuggee process to begin execution:
// executing on xe2x80x9cspecialxe2x80x9d debugger thread
//
ContinueDebugEvent(process_id,thread_id,DBG_CONTINUE);
In order to receive notifications about events occurring in the debuggee, the debugger must then issue a WaitForDebugEvent( ) on the xe2x80x9cspecialxe2x80x9dthread. If INFINITE is specified as the second argument to the call, then the WaitForDebugEvent( ) blocks indefinitely until an event occurs:
// executing on xe2x80x9cspecialxe2x80x9d debugger thread
// blocks until an event occurs
//
DEBUG_EVENT debug_event;
WaitForDebugEvent(anddebug_event, INFINITE);
The debugger can be considered as being in a cycle or loop. Once WaitForDebugEvent( ) returns with an event, the debugger would respond to the event (such as a breakpoint being hit or a child process being spawned) and perform some action based on the event. Then, to restart the debuggee, the debugger would return back on a loop to call ContinueDebugEvent( ) again which will restart the debuggee. The pseudocode for such a cycle might be as follows:
// executing on xe2x80x9cspecialxe2x80x9d debugger thread
//
DEBUG_EVENT debug_event;
for (;;) {
// let the debuggee process run
//
ContinueDebugEvent(process_id,thread_id,DBG_CONTINUE);
// blocks until an event occurs
//
WaitForDebugEvent(anddebug_event,INFINITE);
// handle the event that occurred
//
FunctionToHandleDebugEvent(debug_event);
}
FunctionToHandleDebugEvent( ) will handle the event (such as a breakpoint) returned via the call to WaitForDebugEvent( ) by, for example, updating the state and views of the debugger and/or allowing the user to examine the state of the debuggee or terminate the loop. When the user has finished examining the state of the debuggee, the call to FunctionToHandleDebugEvent( ) will return back to the loop in order to restart the debuggee (unless terminate within FunctionToHandleDebugEvent( )). Indeed, FunctionToHandleDebugEvent( ) can block (not return) until the user wants to restart the debuggee.
This flow of control works well when debugging a single process via this xe2x80x9cspecialxe2x80x9d thread. A problem arises when a child process is created by the process being debugged. If the debuggee at some point spawns another process (for example, for WaitForDebugEvent( ) returns a CREATE_PROCESS_DEBUG_EVENT) then the debugger must manage the newly created process on the same xe2x80x9cspecialxe2x80x9d thread.
To handle the additional process(es), the above loop would need to be modified. ContinueDebugEvent( ) would need to be called for all processes being debugged, not just the original process. This modification is shown below by the addition of the forEachProcessBeingDebugged pseudo-instruction.
// executing on xe2x80x9cspecialxe2x80x9d debugger thread
//
DEBUG_EVENT debug_event;
for (;;) {
// let all the debuggee processes run
//
for EachProcessBeingDebugged{
// let the debuggee process run
//
ContinueDebugEvent(process_id, thread_id,DBG_CONTINUE);
}
// blocks until an event occurs
//
WaitForDebugEvent(anddebuq_event,INFITITE);
// handle the event that occurred
//
FunctionToHandleDebugEvent(debug_event);
}
However, this approach to debugging multiple related processes in the Windows NT and Windows 95 environments can fail. One such scenario is as follows:
1. While process A is being debugged it spawns another process B.
2. ContinueDebugEvent( ) is called for both processes in the loop above so that both process A and process B beg-n execution.
3. WaitForDebugEvent( ) is called and blocks waiting for an event to occur for either process.
4. WaitForDebugEvent( ) returns an event for process A.
The event is handled by FunctionToHandleDebugEvent( ) and it is determined that process A should not be restarted until an event from process B occurs (for example, if the user set one breakpoint in process A and one breakpoint in process B, and wants to examine the state of both processes after both breakpoints have been hit). At this point, process B is still running; the event received for process A stops process A but not process B. So, FunctionToHandleDebugEvent( ) can do one of two things:
a) not return to the loop (block) until the user wants process A to continue execution. However, while FunctionToHandleDebugEvent( ) is waiting for the user, process B, which is still executing, may generate a debug event. So, the user, who is waiting for a debug event to occur for process B, won""t receive the debug event for process B because the loop to call ContinueDebugEvent( ) has not been restarted.
b) flag process A as xe2x80x9cNO_RESTARTxe2x80x9d and return to the loop. In this case, process A and process B would each be flagged initially as xe2x80x9cRESTARTxe2x80x9d and the loop forEachProcessBeingDebugged would be modified to forEachProcessBeingDebuggedAndRESTART in order to call ContinueDebugEvent( ) only for the process(es) that are flagged as xe2x80x9cRESTARTxe2x80x9d, thereby excluding the process(es) flagged as xe2x80x9cNO_RESTARTxe2x80x9d. Thus, ContinueDebugEvent( ) would be called for process B but not for process A. Then, WaitForDebugEvent( ) is called and is blocked waiting for an event from process B (since only process B is running). However, the user may want to restart process A. In this example, the user will have to wait until WaitForDebugEvent( ) unblocks due to an event from process B; the xe2x80x9cspecialxe2x80x9d thread is blocked, waiting for an event from process B, and cannot be used to restart process A.
It is desirable to provide a method, system and article of manufacturer comprising a computer usable medium having computer readable program code means therein for debugging multiple related processes that overcomes the foregoing and other disadvantages of debugging techniques and problems.
Accordingly, it is an object of the invention to provide new and useful methods, systems and articles of manufacture comprising a computer usable medium having computer readable program code means therein for advantageously debugging multiple related processes in a single instance of a debugger.
It is a further object of the invention to provide new and useful methods, systems and articles of manufacture comprising a computer usable medium having computer readable program code means therein that provide the ability for a user to simultaneously debug multiple related processes in order to give the user more control recreating the specific ordering of events that generate a failure in processing.
It is also an object of the invention to provide usability gains and convenience to a user of a debugger, through the ability to debug multiple related processes simultaneously from the same instance of a debugger, by for example allowing the user to view information flowing between processes and the states of the processes.
In accordance with the invention, these and other objects are accomplished by a method for debugging multiple related processes in one instance of a debugger comprising the steps of initiating debugging of a plurality of related processes in said debugger, checking during a timeout period for a debug event that has occurred within said related processes, if a debug event has occurred, processing said debug event, and after said steps of checking or processing, continuing debugging of all related processes. Further, the step of processing said debug event may comprise, if said debug event relates to spawning of a related process, creating a view in a graphical user interface of said debugger with respect to said spawned related process. Indeed, the aforementioned methods may further comprise the steps of selectively designating a process as stopped or determining if any of said related processes are stopped, waiting or running and if there are no processes stopped, waiting or running, terminating the execution of the debugger. Also, said step of processing in said method may comprise, if said debug event relates to termination or completion of a related process, deleting a view in a graphical user interface of said debugger with respect to said terminated or completed related process.
Additionally, the methods may be performed in the Windows NT operating system. Particularly, in the Windows NT operating system, the step of checking may comprise executing the WaitForDebugEvent( ) command for said timeout period and the steps of initiating and continuing comprise executing the ContinueDebugEvent( ) command for said related processes.
A method for debugging a program is provided comprising the steps of designating a plurality of related processes of the program for debugging in a single instance of a debugger, determining during a timeout period whether a debug event has occurred among said plurality of related processes, if a debug event has occurred, processing said debug event, and performing said steps of designating, determining or processing repeatedly until all said related processes are terminated.
Further, in accordance with this invention, an article of manufacture is provided comprising a computer usable medium having computer readable program code means therein for debugging multiple related processes in one instance of a debugger, the computer readable program code means in said computer program product comprising computer readable code means for initiating debugging of a plurality of related processes in said debugger, computer readable code means for checking during a timeout period for a debug event that has occurred within said related processes, computer readable code means for processing said debug event if said debug event has occurred, and computer readable code means for continuing debugging of all related processes after said checking or processing. Further, the computer readable code means of processing said debug event may comprise computer readable code means for, if said debug event relates to spawning of a related process, creating a view in a graphical user interface of said debugger with respect to said spawned related process. The aforesaid article of manufacture may further comprise compute readable code means for selectively designating a process as stopped. The above article of manufacture may further comprise computer readable code means for determining if any of said related processes are stopped, waiting or running, and computer readable code means for, if there are no processes stopped, waiting or running, terminating the execution of the debugger. Also, said computer readable code means of processing said debug event may comprise computer readable code means for, if said debug event relates to termination or completion of a related process, deleting a view in a graphical user interface of said debugger with respect to said terminated or completed related process. Further, said computer readable code means for processing said debug event may comprise computer readable code means for stopping a related process based upon a type of said debug event.
The aforementioned articles of manufacture may comprise computer readable code means is capable of execution in the Windows NT operating system. Further, said computer readable code means for checking may comprise computer readable code means for executing the WaitForDebugEvent( ) command for said timeout period and said computer readable code means for initiating and continuing comprise computer readable code means for executing the ContinueDebugEvent( ) command for said related processes.
An article of manufacture is provided comprising a computer usable medium having computer readable program code means therein for debugging a program, the computer readable program code means in said computer program product comprising computer readable code means for designating a plurality of related processes of the program for debugging in a single instance of a debugged computer readable code means for determining during a timeout period whether a debug event has occurred among said plurality of related processes, computer readable code means for, if a debug event has occurred, processing said debug event, and computer readable code means for performing said steps of designating, determining or processing repeatedly until all said related processes are terminated.
Lastly, a computer system for debugging multiple related processes in one instance of a debugger is provided comprising means for initiating debugging of a plurality, of related processes in said debugger, means for checking during a timeout period for a debug event that has occurred within said related processes, means for processing said debug event if a debug event has occurred, and means for continuing debugging of all related processes after said checking or processing. Also, a computer system for debugging a program is provided comprising means for designating a plurality of related processes of the program for debugging in a single instance of a debugger, means for determining during a timeout period whether a debug event has occurred among said plurality of related processes, means for, if a debug event has occurred, processing said debug event; and means for performing said steps of designating, determining or processing repeatedly until all said related processes are terminated.